-
Notifications
You must be signed in to change notification settings - Fork 706
Make access to Nakamoto staging blocks restricted to one single pub fn #6585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Make access to Nakamoto staging blocks restricted to one single pub fn #6585
Conversation
…ntry Signed-off-by: Jacinta Ferrant <[email protected]>
Signed-off-by: Jacinta Ferrant <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, and looks a lot safer too. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like this PR. It clarifies a lot of aspects around the block storage logic and introduces a clear single entry point for it. Great work on that part!
That said, I have some concerns about moving more business logic into the database layer.
In my view, the DB layer should primarily expose CRUD operations and enforce data integrity (for example, the methods made private in this PR fit well within that responsibility). However, with this change, the DB layer seems to have gained some additional business responsibilities.
This also has implications:
- Maybe less clarity on which layer we should write business logic.
- NakamotoChainState tests now depend (explicitly) on the DB layer’s business logic to run correctly.
- Testing the DB itself becomes a bit more trickier (considering our test organization), since some CRUD methods are now private, we can only test DB behavior indirectly through its business methods (or integration tests). Of course, we could still work around this by adding tests in the same module or child module, requiring different test organization.
To be clear, I’m not suggesting we block this PR. I think the direction is overall positive. I just wanted to open a discussion on this point, since we have similar situations in other DB implementations, and it might be worth aligning on a common approach.
I had the same thought while writing this PR. I hink its better to make the DB operations independent of chainstate logic, but was having a hard time enforcing the privacy restrictions i wanted as a result/I wanted to quickly prove that accept_block was truly the only point of insertion into the db. I do think its worth revisiting/additional effort to enforce better separation while keeping tighter restrictions on the db access. Let me see what I can do today cause I prob didn't give it enough thought. |
Can you elaborate more on this point? What business logic features do you believe are present in the database layer that could be moved out? |
I was thinking specifically store_block_if_better (which mostly calls already existing db functions though). However it does have logic around orphaned blocks, signing weight, etc. that seem a bit like they shouldn't be in the db transaction? But not sure how else to set this up. I would expect the outer caller to do these sorts of checks but then it means exposing all those inner db calls...so this is why I ended up where I ended up |
Right -- |
As part of AAC, determined the desired code path to test should be
accept_block
(which is called in the p2p_broadcast function for miners, and inprocess_new_nakamoto_block_ext
in the Relayer) and that these seemed to be the only points of entry to the staging blocks db. This PR just makes it clear that this is actually the case by making all other writing function calls private in nakamoto block staging db.Confirmed that calling
store_block_if_better
on a shadow block has the same effect as just doingstore_block
. Therefore, we can use it as the single point of entry. I also updated theNakamotoChainState::accept_block
fn sig to be a bit more clear (at least to me), but I can revert that if the old fn sig is preferred.